Method and System for an Efficient Shared-Derived Secret Provisioning Mechanism

ABSTRACT

Embodiments of systems and methods disclosed herein include an embedded secret provisioning system that is based on a shared-derivative mechanism. Embodiments of this mechanism use a trusted third-party topology, but only a single instance of a public-private key exchange is required for initialization. Embodiments of the system and methods are secure and any of the derived secret keys are completely renewable in untrusted environments without any reliance on asymmetric cryptography. The derived secrets exhibit zero knowledge attributes and the associated zero knowledge proofs are open and available for review. Embodiments of systems and methods can be implemented in a wide range of previously-deployed devices as well as integrated into a variety of new designs using minimal roots-of-trust.

RELATED APPLICATIONS

This application is a continuation of and claims the benefit of priorityunder 35 U.S.C. § 120 to U.S. patent application Ser. No. 15/624,318entitled “Method and System for Efficient Shared-Derived SecretProvisioning Mechanism” by William V. Oxford filed Jun. 15, 2017, whichclaims a benefit of priority under 35 U.S.C. § 119 to U.S. ProvisionalPatent Application No. 62/351,601 filed Jun. 17, 2016, entitled “Methodand System for an Efficient Shared-Derived Secret ProvisioningMechanism”, by William V. Oxford et al., which are hereby fullyincorporated by reference in its entirety.

TECHNICAL FIELD

This disclosure relates in general to security in computer systems. Morespecifically, this disclosure relates generally to securely creating anddistributing shared secrets for a device. In particular, certainembodiments relate to efficient shared-derived secret provisioningmechanisms.

BACKGROUND

The ability to securely create and distribute shared secrets is one ofthe more fundamental requirements for a secure architecture. Typically,this function has mostly been accomplished using asymmetric cryptography(crypto) and established Public Key Infrastructure (PKI) mechanisms,including X.509 certificates and Certificate Authorities (CA's). Whilethese methods are well-known and well-suited for traditionalclient-server topologies, the PKI approach can prove challenging forsome emerging Internet of Things (IoT) device classes. Problematicdevices may include those with more limited local computationalcapability or low-bandwidth network connections (or both).

While some IoT devices may have the ability to authenticate and exchangesecret keys using asymmetric crypto, there are an increasingly largenumber of highly-connected (e.g. IoT) devices deployed that lack robustsecurity. One problem with traditional devices is that many of theestablished security threat models are obsolete in todays'increasingly-connected designs. The result of outdated threat modelassumptions is clearly illustrated by the infamous Miller-Valasek remotevehicle exploit that was first made public in 2015. This vulnerabilityserved to illustrate the unforeseen dangers associated with linkingsystems that were designed to be secure in isolation to a widely visiblecommunications network hub.

As such, it should be a guiding principle to assume that for new designsthat they will ultimately be connected in some manner to a publicnetwork. Whether such a device's network connection is accomplished viaa gateway or if the device is attached directly to the internet iscertainly relevant. However, it is definitely not a realisticexpectation that any connected device can rely on the ability of agateway to isolate it from external attack. In order to design as robusta security architecture as possible, it should be assumed that anyconnected device will be continually subjected to externalinterrogation. In order to protect the operation of such connecteddevices from persistent attackers, all communications to and from thedevice should be authenticated, whether or not the data contained in themessage is considered to be confidential. In this latter case, any suchconfidential data should also be encrypted. The essential issue thenbecomes one of secure key management.

In order to enable security in such a system, all devices should beprovisioned with an embedded secret of some kind. In addition, any otherentity with which these devices must securely communicate should also beprovisioned with secrets of their own. In the asymmetric cryptographycase, each of the (private) secrets has a non-secret counterpart thatcan be published without compromising the system's security. In the caseof a symmetric cryptography-based system, devices that wish tocommunicate with each other must share the same secret. While it mightat first glance seem that these two methodologies are fundamentallydifferent, in practice, they share quite a few salient characteristics.

One shared attribute between symmetric and asymmetric cryptographysystems is that they both require a trusted third party at some point inthe process. In the case of an asymmetric system, the trusted thirdparty may take the form of a certificate authority (CA). In symmetriccrypto systems, the overall trust resides in the method by which secretsare provisioned to each of the devices. In the simplest symmetric case,there is a “trusted” location (or environment), where a shared secretcan be directly transmitted between two devices without fear of someuntrusted party eavesdropping on the communication. This approachgenerally requires physical isolation and it is thus not usuallypractical after a device has been deployed in the field

A more complex (but more flexible) shared-secret system makes use ofsecured communications between each device and an independent trustedthird party. The trusted third party exchanges information with each ofthe individual devices in order to enable secure connections between theuntrusted devices. As with all such systems, there are certainassumptions that must be made in order to support the stated systems'security claims. The increased flexibility of such a trusted third-partyexchange system is due to the fact that new keys may be provisioned todevices after they have been deployed in the field without requiring atrusted location in which to perform key exchanges or key rotations.

A less-appreciated, but nonetheless common characteristic of anyapproach to the problem is that both symmetric as well as asymmetricsecurity systems depend on the ability of an individual device tomaintain control of its own private secrets. For an asymmetric system,all devices must be trusted to not inadvertently reveal their ownprivate secrets. In the case of symmetric crypto systems, more than onedevice must be entrusted with the safekeeping of the same shared secret.In either case, if any of these private secrets are ever exposed, theoverall security of the system can break down. Thus, all secure devicesmust be able to retain and use a secret of some sort without exposingits value.

Accordingly, there is a need to find systems and methods by which thedata of such security systems may likewise be secured, where by securingsuch data, the effectiveness of such a security system may be enhanced.

These, and other, aspects of the disclosure will be better appreciatedand understood when considered in conjunction with the followingdescription and the accompanying drawings. It should be understood,however, that the following description, while indicating variousembodiments of the disclosure and numerous specific details thereof, isgiven by way of illustration and not of limitation. Many substitutions,modifications, additions and/or rearrangements may be made within thescope of the disclosure without departing from the spirit thereof, andthe disclosure includes all such substitutions, modifications, additionsand/or rearrangements.

SUMMARY OF THE DISCLOSURE

In a first example, an embedded secret provisioning systems is based ona shared-derivative (as opposed to a more straightforward shared-secret)mechanism. Embodiments of this mechanism use a trusted third-partytopology, but only a single instance of a public-private key exchange isrequired for initialization. Embodiments of the system are secure andany of the derived secret keys are completely renewable in untrustedenvironments without any reliance on asymmetric cryptography. Thederived secrets exhibit zero knowledge attributes and the associatedzero knowledge proofs are open and available for review.

A security core includes a pair of keyed one-way secure hash functionblocks and a pair of associated embedded key registers. A first embeddedkey register is fixed and a second embedded key register is variable. Ina provisioning process, a known value is stored in the first embeddedkey register and represents the root of the device, and is onlyprogrammable once. Once initialized with an embedded secret value itcannot be changed or read by external observers. Using the pair of keyedone-way secure hash function blocks and the second embedded keyregister, various derived secrets can be generated and used, as desired.

These, and other, aspects of the disclosure will be better appreciatedand understood when considered in conjunction with the followingdescription and the accompanying drawings. It should be understood,however, that the following description, while indicating variousembodiments of the disclosure and numerous specific details thereof, isgiven by way of illustration and not of limitation. Many substitutions,modifications, additions and/or rearrangements may be made within thescope of the disclosure without departing from the spirit thereof, andthe disclosure includes all such substitutions, modifications, additionsand/or rearrangements.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings accompanying and forming part of this specification areincluded to depict certain aspects of the disclosure. It should be notedthat the features illustrated in the drawings are not necessarily drawnto scale. A more complete understanding of the disclosure and theadvantages thereof may be acquired by referring to the followingdescription, taken in conjunction with the accompanying drawings inwhich like reference numbers indicate like features and wherein:

FIG. 1 depicts one embodiment of an architecture for contentdistribution.

FIG. 2 depicts one embodiment of a target device.

FIG. 3 depicts a block diagram of an embodiment of a security core,including a pair of keyed one-way secure hash function blocks and a pairof associated embedded key registers.

FIG. 4 is a block diagram depicting an example of a basic embedded keyregister structure.

FIG. 5 depicts a block diagram of an embodiment of a security coreduring the initial provisioning process.

FIG. 6 depicts a block diagram showing an embodiment ofnewly-initialized security core using the initially provisioned secretto produce a derivative secret.

FIG. 7 depicts a block diagram of another embodiment of a security coreillustrating how a secure command input is formed by the consolidationof external input data.

FIG. 8 is a sequence diagram illustrating an embodiment of a method forregistering a device with a new provisioning service.

FIG. 9 is a sequence diagram illustrating a post-registration secureprovisioning process that may occur in the field.

FIG. 10 depicts a block diagram of a secure core that supports group keyoperation.

DETAILED DESCRIPTION

The disclosure and the various features and advantageous details thereofare explained more fully with reference to the non-limiting embodimentsthat are illustrated in the accompanying drawings and detailed in thefollowing description. Descriptions of well-known starting materials,processing techniques, components and equipment are omitted so as not tounnecessarily obscure the invention in detail. It should be understood,however, that the detailed description and the specific examples, whileindicating some embodiments of the invention, are given by way ofillustration only and not by way of limitation. Various substitutions,modifications, additions and/or rearrangements within the spirit and/orscope of the underlying inventive concept will become apparent to thoseskilled in the art from this disclosure.

Before discussing embodiments in detail, it may helpful to give ageneral overview of an architecture and topologies in which embodimentsof the present invention may be effectively utilized. Commonly-assignedU.S. Pat. No. 8,438,392, entitled Method and System for Control of CodeExecution on a General Purpose Computing Device and Control of CodeExecution in a Recursive Security Protocol issued on May 7, 2013 andincorporated by reference herein, may also be useful to an understandingof such architectures and topologies.

FIG. 1 depicts one embodiment of such a topology. Here, a contentdistribution system 101 may operate to distribute digital content (whichmay be for example, a bitstream comprising audio or video data, asoftware application, etc.) to one or more target units 100 (alsoreferred to herein as target or endpoint devices) which compriseprotocol engines. These target units may be part of, for example,computing devices on a wireline or wireless network or a computer devicewhich is not networked, such computing devices including, for example, apersonal computers, cellular phones, personal data assistants, mediaplayers which may play content delivered as a bitstream over a networkor on a computer readable storage media that may be delivered, forexample, through the mail, etc. This digital content may compose or bedistributed in such a manner such that control over the execution of thedigital content may be controlled and security implemented with respectto the digital content.

In certain embodiments, control over the digital content may beexercised in conjunction with a licensing authority 103. This licensingauthority 103 (which may be referred to as a central licensingauthority, though it will be understood that such a licensing authorityneed not be centralized and whose function may be distributed, or whosefunction may be accomplished by content distribution system 101, manualdistribution of data on a hardware device such as a memory stick, etc.)may provide a key or authorization code. This key may be a compound key(DS), that is both cryptographically dependent on the digital contentdistributed to the target device and bound to each target device (TDn).In one example, a target device may be attempting to execute anapplication in secure mode. This secure application (which may bereferred to as candidate code or a candidate code block (e.g., CC)) maybe used in order to access certain digital content.

Accordingly, to enable a candidate code block to run in secure mode onthe processor of a particular target device 100 to which the candidatecode block is distributed, the licensing authority 103 must supply acorrect value of a compound key (one example of which may be referred toas an Authorization Code) to the target device on which the candidatecode block is attempting to execute in secure mode (e.g., supply DS1 toTD1). No other target device (e.g., TDn, where TDn≠TD1) can run thecandidate code block correctly with the compound key (e.g., DS1) and noother compound key (DSn assuming DSn≠DS1) will work correctly with thatcandidate code block on that target device 100 (e.g., TD1).

As will be described in more detail later on herein, when Target Device100 (e.g., TD1) loads the candidate code block (e.g., CC1) into itsinstruction cache (and, for example, if CC1 is identified as code thatis intended to be run in secure mode), the target device 100 (e.g., TD1)engages a hash function (which may be hardware based) that creates amessage digest (e.g., MD1) of that candidate code block (e.g., CC1). Theseed value for this hash function is the secret key for the targetdevice 100 (e.g., TD1's secret key (e.g., SK1)).

In fact, such a message digest (e.g., MD1) may be a MessageAuthentication Code (MAC) as well as a compound key, since the hashfunction result depends on the seed value of the hash, the secret key ofthe target device 100 (e.g., SK1). Thus, the resulting value of themessage digest (e.g., MD1) is cryptographically bound to both the secretkey of the target device 100 and to the candidate code block. If thelicensing authority distributed compound key (e.g., DS1) matches thevalue of the message digest (e.g., MD1) it can be assured that thecandidate code block (e.g., CC1) is both unaltered as well as authorizedto run in secure mode on the target device 100 (e.g., TD1). The targetdevice 100 can then run the candidate code block in secure mode.

As can be seen then, in one embodiment, when secure mode execution for atarget device 100 is performed the target device 100 may be executingcode that has both been verified as unaltered from its original form,and is cryptographically “bound” to the target device 100 on which it isexecuting. This method of ensuring secure mode execution of a targetdevice may be contrasted with other systems, where a processor enterssecure mode upon hardware reset and then may execute in a hypervisormode or the like in order to establish a root-of-trust.

Accordingly, using embodiments as disclosed, any or all of these datasuch as the compound key from the licensing authority, the messagedigest, the candidate code block, etc. (e.g., DS1, MD1, CC1) may becompletely public as longs as the secret key for the target device 100(e.g. SK1) is not exposed. Thus, it is desired that the value of thesecret key of a target device is never exposed, either directly orindirectly. Accordingly, as discussed above, embodiments of the systemsand methods presented herein, may, in addition to protecting the secretkey from direct exposure, protect against indirect exposure of thesecret key on target devices 100 by securing the working sets ofprocesses executing in secure mode on target devices 100.

Moving now to FIG. 2, an architecture of one embodiment of a targetdevice that is capable of controlling the execution of the digitalcontent or implementing security protocols in conjunction with receiveddigital content. Elements of the target unit may include a set ofblocks, which allow a process to execute in a secured mode on the targetdevice such that when a process is executing in secured mode the workingset of the process may be isolated. It will be noted that while theseblocks are described as hardware in this embodiment, software may beutilized to accomplish similar functionality with equal efficacy. Itwill also be noted that while certain embodiments may include all theblocks described herein other embodiments may utilize lesser oradditional blocks.

The target device 100 may comprise a CPU execution unit 120 which may bea processor core with an execution unit and instruction pipeline. Clockor date/time register 102 may be a free-running timer that is capable ofbeing set or reset by a secure interaction with a central server. Sincethe time may be established by conducting a query of a secure timestandard, it may be convenient to have this function be on-chip. Anotherexample of such a date/time register may be a register whose value doesnot necessarily increment in a monotonic manner, but whose value doesnot repeat very often. Such a register could be useful in the case wherea unique timestamp value might be required for a particular reason, butthat timestamp value could not necessarily be predicted ahead of time.Thus, a pseudo-random number generator may be a suitable mechanism forimplementing such a register. Another option for implementing such afunction would be to use the output of a hardware hash function 160 toproduce the current value of this register. In the case where the outputof such a hash function is used as a seed or salt value for the input ofthe hash function, the resulting output series may resemble a randomnumber sequence statistically, but the values may nonetheless bedeterministic, and thus, potentially predictable. Target unit 100 mayalso contain a true random number generator 182 which may be configuredto produce a sequence of sufficiently random numbers or which can thenbe used to supply seed values for a pseudo-random number generationsystem. This pseudo-random number generator can also potentially beimplemented in hardware, software or in “secure” software.

One-way hash function block 160 may be operable for implementing ahashing function substantially in hardware. One-way hash function block160 may be a part of a secure execution controller 162 that may be usedto control the placement of the target device 100 in secure mode or thatmaybe used to control memory accesses (e.g., when the target device 100is executing in secured mode), as will be described in more detailherein at a later point.

In one embodiment, one way has function block 160 may be implemented ina virtual fashion, by a secure process running on the very same CPU thatis used to evaluate whether a given process is secure or not. In certainembodiments two conditions may be adhered to, ensuring that such asystem may resolve correctly. First, the secure mode “evaluation”operation (e.g., the hash function) proceeds independently of theexecution of the secure process that it is evaluating. Second, a chainof nested evaluations may have a definitive termination point (which maybe referred to as the root of the “chain of trust” or simply the “rootof trust”). In such embodiments, this “root of trust” may be the minimumportion of the system that should be implemented in some non-changeablefashion (e.g., in hardware). This minimum feature may be referred to asa “hardware root of trust”. For example, in such embodiments, one suchhardware root of trust might be a One-Way hash function that is realizedin firmware (e.g., in non-changeable software).

Another portion of the target unit 100 may be a hardware-assistedencryption/decryption block 170 (which may be referred to as theencryption system or block, the decryption system or block or theencryption/decryption block interchangeably), which may use either thetarget unit's 100 secret key(s) or public/private keys (described later)or a derivative thereof, as described earlier. Thisencryption/decryption block 170 can be implemented in a number of ways.It should also be noted that such a combination of a One-Way HashFunction and a subsequent encryption/decryption system may comprise adigital signature generator that can be used for the validation of anydigital data, whether that data is distributed in encrypted or inplaintext form. The speed and the security of the entire protocol mayvary depending on the construction of this block, so it may beconfigured to be both flexible enough to accommodate security systemupdates as well as fast enough to allow the system to perform real-timedecryption of time-critical messages.

It is not material to embodiments exactly which encryption algorithm isused for this hardware block 170. In order to promote the maximumflexibility, it is assumed that the actual hardware is general-purposeenough to be used in a non-algorithmically specific manner, but thereare many different means by which this mechanism can be implemented. Itshould be noted at this point that the terms encryption and decryptionwill be utilized interchangeably herein when referring to engines(algorithms, hardware, software, etc.) for performingencryption/decryption. As will be realized if symmetric encryption isused in certain embodiments, the same or similar encryption ordecryption engine may be utilized for both encryption and decryption. Inthe case of an asymmetric mechanism, the encryption and decryptionfunctions may or may not be substantially similar, even though the keysmay be different.

Target device 100 may also comprise a data cache 180, an instructioncache 110 where code that is to be executed can be stored, and mainmemory 190. Data cache 180 may be almost any type of cache desired suchas a L1 or L2 cache. In one embodiment, data cache 180 may be configuredto associate a secure process descriptor with one or more pages of thecache and may have one or more security flags associated with (all orsome subset of the) lines of a data cache 180. For example, a secureprocess descriptor may be associated with a page of data cache 180.

Generally, embodiments of target device 100 may isolate the working setof a process executing in secure mode stored in data cache 180 such thatthe data is inaccessible to any other process, even after the originalprocess terminates. More specifically, in one embodiment, the entireworking set of a currently executing may be stored in data cache 180 andwrites to main memory 190 and write-through of that cache (e.g., to mainmemory 190) disallowed (e.g., by secured execution controller 162) whenexecuting in secured mode.

Additionally, for any of those lines of data cache 180 that are writtento while executing in secure mode (e.g., a “dirty” cache line) thosecache lines (or the page that comprises those cache lines) may beassociated with a secure process descriptor for the currently executingprocess. The secure process descriptor may uniquely specify thoseassociated “dirty” cache lines as belonging to the executing secureprocess, such that access to those cache lines can be restricted to onlythat process (e.g. be by secured execution controller 162).

In certain embodiments, in the event that the working set for a secureprocess overflows data cache 180 and portions of data cache 180 thatinclude those dirty lines associated with the security descriptor of thecurrently executing process need to be written to main memory (e.g., apage swap or page out operation) external data transactions between theprocessor and the bus (e.g., an external memory bus) may be encrypted(e.g., using encryption block 170 or encryption software executing insecure mode). The encryption (and decryption) of data written to mainmemory may be controlled by secure execution controller 162.

The key for such an encryption may be the secure process descriptoritself or some derivative thereof and that secure descriptor may itselfbe encrypted (e.g., using the target device's 100 secret key 104 or somederivative thereof) and stored in the main memory 190 in encrypted formas a part of the data being written to main memory.

Instruction cache 110 is typically known as an I-Cache. In someembodiments, a characteristic of portions of this I-Cache 110 is thatthe data contained within certain blocks be readable only by CPUexecution unit 120. In other words, this particular block of I-Cache 130is execute-only and may not be read from, nor written to, by anyexecuting software. This block of I-Cache 130 will also be referred toas the “secured I-Cache” 130 herein. The manner by which code to beexecuted is stored in this secured I-Cache block 130 may be by way ofanother block which may or may not be depicted. Normal I-Cache 150 maybe utilized to store code that is to be executed normally as is known inthe art.

Additionally, in some embodiments, certain blocks may be used toaccelerate the operation of a secure code block. Accordingly, a set ofCPU registers 140 may be designated to only be accessible while the CPU120 is executing secure code or which are cleared upon completion ofexecution of the secure code block (instructions in the secured I-cacheblock 130 executing in secured mode), or if, for some reason a jump toany section of code which is located in the non-secure or “normal”I-Cache 150 or other area occurs during the execution of code stored inthe secured I-Cache 130.

In one embodiment, CPU execution unit 120 may be configured to trackwhich registers 140 are read from or written to while executing the codestored in secured I-cache block 130 and then automatically clear ordisable access to these registers upon exiting the “secured execution”mode. This allows the secured code to quickly “clean-up” after itselfsuch that only data that is permitted to be shared between two kinds ofcode blocks is kept intact. Another possibility is that an author ofcode to be executed in the secured code block 130 can explicitlyidentify which registers 140 are to be cleared or disabled. In the casewhere a secure code block is interrupted and then resumed, then thesedisabled registers may potentially be re-enabled if it can be determinedthat the secure code that is being resumed has not been tampered withduring the time that it was suspended.

In one embodiment, to deal with the “leaking” of data stored inregisters 140 between secure and non-secure code segments a set ofregisters 140 which are to be used only when the CPU 120 is executingsecured code may be identified. In one embodiment, this may beaccomplished utilizing a version of the register renaming andscoreboarding mechanism, which is practiced in many contemporary CPUdesigns. In some embodiments, the execution of a code block in securedmode is treated as an atomic action (e.g., it is non-interruptible)which may make this such renaming and scoreboarding easier to implement.

Even though there may seem to be little possibility of the CPU 120executing a mixture of “secured” code block (code from the securedI-Cache 130) and “unsecured code” (code in another location such asnormal I-cache 150 or another location in memory), such a situation mayarise in the process of switching contexts such as when jumping intointerrupt routines, or depending on where the CPU 120 context is stored(most CPU's store the context in main memory, where it is potentiallysubject to discovery and manipulation by an unsecured code block).

In order to help protect against this eventuality, in one embodimentanother method which may be utilized for protecting the results obtainedduring the execution of a secured code block that is interruptedmid-execution from being exposed to other execution threads within asystem is to disable stack pushes while a the target device 100 isoperating in secured execution mode. This disabling of stack pushes willmean that a secured code block is thus not interruptible in the sensethat, if the secured code block is interrupted prior to its normalcompletion, it cannot be resumed and therefore must be restarted fromthe beginning. It should be noted that in certain embodiments if the“secured execution” mode is disabled during a processor interrupt, thenthe secured code block may also potentially not be able to be restartedunless the entire calling chain is restarted.

Each target unit 100 may also have one or more secret key constants 104;the values of neither of which are software-readable. In one embodiment,the first of these keys (the primary secret key) may be organized as aset of secret keys, of which only one is readable at any particulartime. If the “ownership” of a unit is changed (for example, theequipment containing the protocol engine is sold or its ownership isotherwise transferred), then the currently active primary secret key maybe “cleared” or overwritten by a different value. This value can eitherbe transferred to the unit in a secure manner or it can be alreadystored in the unit in such a manner that it is only used when this firstkey is cleared. In effect, this is equivalent to issuing a new primarysecret key to that particular unit when its ownership is changed or ifthere is some other reason for such a change (such as a compromisedkey). A secondary secret key may be utilized with the target unit 100itself. Since the CPU 120 of the target unit 100 cannot ever access thevalues of either the primary or the secondary secret keys, in somesense, the target unit 100 does not even “know” its own secret keys 104.These keys are only stored and used within the security executioncontroller 162 of the target unit 100 as will be described.

In another embodiment, the two keys may be constructed as a list of“paired” keys, where one such key is implemented as aone-time-programmable register and the other key in the pair isimplemented using a re-writeable register. In this embodiment, there-writeable register may be initialized to a known value (e.g., zero)and the only option that may be available for the system to execute insecure mode in that state may be to write a value into the re-writeableportion of the register. Once the value in this re-writeable register isinitialized with some value (e.g., one that may only be known by theLicensing Authority, for example), then the system may only then be ableto execute more general purpose code while in secure mode. If thisre-writeable value should be re-initialized for some reason, then theuse of a new value each time this register is written may provideincreased security in the face of potential replay attacks.

Yet another set of keys may operate as part of a temporarypublic/private key system (also known as an asymmetric key system or aPKI system). The keys in this pair may be generated on the fly and maybe used for establishing a secure communications link between similarunits, without the intervention of a central server. As the security ofsuch a system is typically lower than that of an equivalent key lengthsymmetric key encryption system, these keys may be larger in size thanthose of the set of secret keys mentioned above. These keys may be usedin conjunction with the value that is present in the on-chip timer blockin order to guard against “replay attacks”, among other things. Sincethese keys may be generated on the fly, the manner by which they aregenerated may be dependent on the random number generation system 180 inorder to increase the overall system security.

In one embodiment, one method that can be used to affect a change in“ownership” of a particular target unit is to always use the primarysecret key as a compound key in conjunction with another key 107, whichwe will refer to as a timestamp or timestamp value, as the value of thiskey may be changed (in other words may have different values atdifferent times), and may not necessarily reflect the current time ofday. This timestamp value itself may or may not be itselfarchitecturally visible (e.g., it may not necessarily be a secret key),but nonetheless it will not be able to be modified unless the targetunit 100 is operating in secured execution mode. In such a case, theconsistent use of the timestamp value as a component of a compound keywhenever the primary secret is used can produce essentially the sameeffect as if the primary secret key had been switched to a separatevalue, thus effectively allowing a “change of ownership” of a particulartarget endpoint unit without having to modify the primary secret keyitself.

Embodiments of the invention provide a simple and effective method forauthentication and activation in a device assembly. An exemplaryassembly may include one or more semiconductor devices assembled on amotherboard or module by a systems integrator. The assembled device mayultimately be activated by a service provider and used by a user to runone or more application developed by a software vendor. For the deviceto function securely, the various components and systems (e.g.,semiconductor manufacturer, systems integrator, service provider,software vendor, user, etc.) used in a given task must cooperate, eventhough underlying entities may not share trust among one another. Oneimportant benefit of the mechanisms described is that the dataencryption used by the system can be accomplished without usingasymmetric encryption, which is inefficient and processor intensive. Forexample, in the mechanisms described below, the data encryption can beaccomplished using symmetric encryption, which is much more efficientthan asymmetric encryption.

In some embodiments, the embodiments relate to an efficient and secureauthorization system using a distributed device activation procedure.Other embodiments relate to an efficient and secure authenticationsystem using a hierarchical activation mechanism (such as that describedin commonly-assigned U.S. patent application Ser. No. 15/167,254, filedMay 27, 2016, entitled “DISTRIBUTED AND HIERARCHICAL DEVICE ACTIVATIONMECHANISMS,” which is hereby incorporated by reference in its entiretyas if fully set forth herein).

Generally, following is a description of exemplary embedded secretprovisioning systems that are based on a shared-derivative (as opposedto a more straightforward shared-secret) mechanism. Embodiments of thismechanism use a trusted third-party topology, but, in some examples,only a single instance of a public-private key exchange is required forinitialization. In operation, embodiments of the system are secure andany of the derived secret keys are completely renewable in untrustedenvironments without any reliance on asymmetric cryptography. As opposedto more traditional shared-secret based systems, the derived secretsexhibit Zero Knowledge attributes and the associated Zero Knowledgeproofs are open and available for review. Embodiments of thisprovisioning mechanism are ISA-agnostic and do not depend on anyspecific set of CPU architectural features. Thus, this system can beimplemented in a wide range of previously-deployed devices as well asintegrated into a variety of new designs using minimal roots-of-trust.

In certain embodiments, the most basic building block required tosupport this protocol consists of a security core, described below. FIG.3 is a block diagram of an embodiment of a security core 300, includinga pair of keyed one-way secure hash function blocks (keyed hash A 302and keyed hash B 304) and a pair of associated embedded key registers,one fixed (static) (embedded key A 306) and one variable (embedded key B308). Some of the device internal control lines in the block diagramshown in FIG. 3 have been deemphasized (shown by dashed lines) in orderto accentuate the primary feature, which is the paired keyed hashmechanism (keyed hash A 302 and keyed hash B 304) and the associatedembedded keys (embedded key A 306 and embedded key B 308).

The secure core 300 itself is a monolithic function block in certainembodiments. The secure core 300 includes several (public) data inputs(external reference code input 310, external message input 312, andexternal data 314) and the resulting (also public) outputs (single bit“Secure” indicator 316 and resulting MAC output 318). The (private)internal signals are shown by solid lines. Once the structure isproperly provisioned with embedded secret(s) (described below), theinternal signals are not visible outside of the security core 300boundary.

There are several important aspects that should be understood regardingthe embodiment of the structure shown in FIG. 3. First, the basicoperation of the secure core 300 is not dependent on any specificone-way hash algorithm or any implementation thereof. Second, themechanism shown in FIG. 3 has been depicted with two distinct hashfunctions (302, 304). This dual-hash structure representation is donefor the sake of clarity, but the mechanism can easily be implementedwith a single hash function block coupled to a simple state machine toobtain the same result as the structure shown above. Similarly, the hashfunctions can be performed using hardware or software, as desired.

FIG. 4 is a block diagram illustrating one example of a basic embeddedkey register structure 400. Focusing on the embedded key itself, in theembodiment depicted in FIG. 4 we can see that this structure consists oftwo main components: a core ID field 402 and an embedded secret field404. The core ID field 402 functions in a manner similar to a standardserial number and this portion of the embedded key data structure 400 isnot secret. However, the embedded secret portion 404 should never bemade visible to the outside world, either directly or indirectly, inorder for the device to operate in a secure fashion. In addition totheir differences from an external visibility perspective, these twocomponent fields also are initialized using slightly differentmechanisms. Nonetheless, from the perspective of the operation of thekeyed hash functions (302, 304), the combined embedded key 400 can beconsidered as a single monolithic register, albeit with differentvisibility attributes for different portions of the register.

From the cryptographic perspective, it should be noted that the embeddedsecret portion 404 of an embedded key 400 may only be used in the keyinputs to a keyed hash function. Thus, the secret portions of theseembedded key registers are not ever used directly nor are they capableof being used in isolation (even including the evaluation of the keyedhash functions). The only way that information contained within anembedded secret 404 can propagate to the outside world is through theresult of evaluating at least one pass through a secure keyed hashfunction. Such output derivative values must also depend not only on thesecret data, but also some other input data (including both the visibleportions of the embedded keys as well as some externally-supplied inputdata to the keyed hash function). Only such derivative values are ableto be used as an input to subsequent cryptographic operations.

Returning to FIG. 3, it should also be noted that the externalvisibility of the keyed hash B function 304 output is gated (via gate320) by the (e.g., single-bit) result of the comparison between theInternally-calculated reference (the output of the keyed hash A function302) and the (public) reference code input 310. If the result (output316) of this comparison (referred to as the “secure mode” indictor) is a“1” (meaning that the two reference values match), then the output ofthe keyed hash B block 304 is allowed to propagate (via gate 320) to theoutside world at the resulting message authentication code (MAC) output318.

If the result of the comparison is not a “1”, then the internal MACoutput 322 is not allowed to propagate (via gate 320) outside of thesecurity core 300. The effect of this arrangement is that, in certainembodiments, the only means by which an output from either of thedevice's keyed hash functions 302 or 304 can be made visible outside thesecurity core boundary is through the action of a correctly-constructedexternal reference code input 310. However, this external reference code310 can only be correctly constructed by an entity that is in possessionof the very same embedded secrets from which the output is derived.

If the hash functions 302, 304 are assumed to be non-invertible (withincomputational complexity bounds), then one of the more fundamentalconcepts that can be verified from the block diagram shown in FIG. 3 isthat neither of the embedded secret values can be determined by anoutside observer in any manner other than by a (birthday-attack bound)random guess. Thus, it is not practical for an outside observer (whodoes not know the values of the embedded secrets) to predict a securitycore output resulting from any given input message. To an observer whois not in possession of a device's embedded secrets, but who can observethe system's input data, this output nonetheless appears similar innature to that of a pseudo-random number generator (PRNG), although theactual output data is clearly dependent on the input and it is alsoobviously completely deterministic.

Finally, it should be noted that embodiments of this protocol can berealized in its entirely using a very low-complexity hardware design.Alternately, it can also be accomplished in software running on anystandard processor that supports a suitably secure operational model. Ofcourse, it is also possible to implement this security core using astandard hardware security module (HSM) platform, if the HSM supports asuitable keyed hash function and provided that its secure functions canbe properly cascaded. In fact, there are a number of different means bywhich this basic “dual keyed hash, dual secret” structure may beimplemented. The exact implementation choices made in the constructionof this function will depend on various tradeoffs between the amount of“fixed” (i.e. One-time-programmable or OTP) registers, “static” or“persistent” (e.g. battery-backed or Flash memory-based) registers andcomputational resources available to the system designer. The basicstructure shown in FIG. 3 is simply presented in a way that most easilyillustrates the core operating principles.

Following is a description of examples of initial device provisioning.Uninitialized devices may be those with unique serial numbers (i.e.,CoreIDs), but no embedded secrets. Such devices are not capable ofsecure operation. The initialization process need not be performed atthe chip fab. Uninitialized, but otherwise fully functional devices maybe safely shipped to OEM assembly houses or to dedicated securefacilities for initial provisioning. FIGS. 5 and 6 illustrate anembodiment of a two-step process by which a device can be initialized(or “provisioned”) at any suitable secure provisioning location. FIG. 7shows how a provisioned device may then be registered with one or morethird party service providers.

The first step in the provisioning process (shown in FIG. 5) is tocreate and program a known value (at input 328) into the embedded secretportion 404 (FIG. 4) of the device's embedded key A register 306. Thisembedded secret value represents the “root” (entropy seed) of the deviceand it is only programmable once. Once the part has been initializedwith this embedded secret value, the OTP fuse 324 is burned, and theembedded secret value can neither be changed nor read back by externalobservers (authorized or not). Since this value represents the “root oftrust” for the device's secure core 300, it should be generated withgreat care (e.g., it should exhibit good entropy).

Next, the embedded secret created in the previous step must thus beused, along with an arbitrarily-chosen external message input (input312), to create an external reference code input for the device. Thesetwo numbers (the external message/reference code pair) arecryptographically bound to the device's root of trust (i.e., to thedevice's embedded key A value). Without at least one suchcryptographically bound pair, the device's secure core is not usable. Itshould be noted, however, that even if both of these numbers are madepublic, such knowledge will not enable the device's “embedded secret”(root of trust) value to be exposed, either directly or indirectly.

If desired, more than one set of external message/reference code inputpairs may be created during the initialization procedure, but after thatis accomplished, the core's embedded secret value should be discarded.In this manner, the device's embedded secret need not be escrowedanywhere and, in fact, it should probably never be stored, for privacyand liability reasons. In the case where the device's embedded secret isinternally-produced via some other mechanism (such as a PUF blockoutput, for example), then this embedded secret value should never leavethe device after the initialization procedure has been completed. If thedevice has the ability to generate both repeatable (e.g. PUF-style) andephemeral entropy values on-chip, then such a device may be constructedin a manner that automatically produces the cryptographically-boundpairs described above without ever requiring that the embedded secretvalue be externally visible, even including during the initializationprocess. In such a case, then the “OTP” fuse bit 324 can be used todisable the generation of further cryptographically-bound pairs asdescribed above. Once the OTP fuse bit 324 has been blown, theoperational consequence for the device is the same, whether the device'sembedded secret is externally-provided or internally-generated.

While the quality of the entropy for the device's embedded secret may beof paramount importance to the device's secure operation, the selectionof the external message input(s) 312 used to create the associatedexternal reference code (the output of hash function block 302) has muchless impact on the system's overall security. This externalmessage/reference code mechanism operates in a manner that is analogousto a password-based key derivation function (PBKDF). This means that thesystem can quickly generate moderate levels of effective operatingentropy (internal reference values) from even low-entropy input stimuli(external messages 312). This is discussed below.

The next step (shown in FIG. 6) begins with a power-up reset of thenewly-initialized device. Immediately after exiting the power-up resetstate (i.e., T=0), the contents of the embedded Key (secret) A register306 are transferred into the embedded key (secret) B register 308 viaMUX 330. This embedded secret value is now present at the key inputs ofthe two keyed hash blocks 302 and 304. From this point on, the devicecan operate securely. However, as soon as the embedded key B register308 is loaded, the internal reference value (the output 332 of the keyedhash A block 302) will also be updated. At that point, the output 316 ofthe internal comparator (the “secure” indicator) will then be clearedand the resulting MAC output will be disabled via gate 320.

As described earlier, the secure core's resulting MAC output 318 may beconditioned on whether or not the device has been provided with acorrect external reference code input value (at input 310). The correctvalue for this reference code input 310 can only be calculated by anentity who is in possession of the secure core's “embedded secret A” (inaddition to the Corel D, but the CoreID information is known). Alsointeresting to note is that the external control input that allows adevice to update the embedded key B register 308 via the “write_secret”326 input is also disabled in this case since this control input toregister 308 is also conditioned on the “secure mode” bit 316. Asbefore, only an entity who is in possession of the secure core's“embedded secret A” will be able to know the correct value for thereference code input 310 that is required to set this “secure mode” bit316 to a “true”. So, the embedded key B register 308 will also no longerbe able to be updated unless the device is presented with acorrectly-constructed external message/reference code pair. Thus, in theabsence of such a valid external input pair, the secure core will remainquiescent. In effect, a valid external message/reference code input pairacts as an “unlock key” for the secure core. Since the key is public,this secure core “unlock” feature is subject to a significant replayattack weakness, where an attacker could replay a valid “write_secret”command but with an arbitrary (potentially malicious) external datainput 314. Discussed below is a simple and inexpensive means fordefending against this replay attack.

Consider the modified arrangement shown in the embodiment of FIG. 7. Inthis version of the design, we have incorporated the “write_secret”control input 326 mentioned above with a combined ExternalMessage/External Data input. Effectively, we have consolidated theprevious External inputs (Message+Data+write_secret control) into asingle monolithic “Secure Command” input 334 for the device. As with theprevious version, there is an associated External reference code input310 for this Secure Command 334 that cannot be predicted by an attackerwithout knowledge of the device's embedded secret. Since the“write_secret” bit has now been included in the Internal Referencecalculation, it can also be seen that there are now two variants foreach “Secure Command” that can be executed by a given secure core. Thismeans that there are also two accompanying reference code input pairs(one for the Secure Command where the write_secret bit is a “1” and theother where the write_secret bit is a “0”). We will refer to these twooperations as “Sign_msg” and “write_secret” commands. Both variants ofthe command will produce the same Internal MAC output from the securecore (as long as they are given the same External Data input), but theywill require different reference code inputs in order to execute the twocommands securely. Knowing a valid External reference code input for oneoperation will not allow an attacker to guess the proper reference valuefor the other command.

In the previous version of the design (shown in the embodiment of FIG.6), we noted the potential for a replay attack, based on repeating theprevious “write_secret” command (along with its associated externalreference code input) paired with some arbitrary (potentially malicious)external data input. Fortunately, this issue can be simply andeffectively solved by adding a single internal register 336 to thedevice (as shown in the embodiment of FIG. 7). The purpose of thisregister 336 is to save a copy of a secure command's external messageinput data field from the last successful “write_secret” command for usein the validation of a subsequent operation. Thus, if a successful“write_secret” command is ever repeated, its external reference codeinput will no longer be valid, since the internal value of this“previous write_secret external message input” register has beenupdated. In this manner, the External Message input data acts both as anentropy input (for the creation of new embedded secrets) as well as anonce. This is a simple, but highly effective replay attack preventionmechanism.

In effect, the entity in possession of a device's current embeddedsecret can use that information to create an external reference codethat can compel the device to update its secret to a new value. Thus,the entity with the knowledge of a device's current embedded secret actsas the “owner” of that device and only the “owner” of a device mayprovide the necessary information to transfer ownership of the device toa subsequent “owner”. Note that an external attacker could ostensiblyrepeat the secure command sequence that writes a particular value to theEmbedded Key B register 308 and then subsequently update its value to anew value (from the Internal MAC output of Hash block 304). However,this is not a replay attack per-se, since the only thing that theattacker can do is to repeat exactly the same sequence and place thedevice in exactly the same state as before. In other words, a potentialreplay attacker cannot act in a way that will cause the Embedded Key Bregister 308 to contain some value other than exactly the originallyintended one. In addition, the actual value that is written into theEmbedded Key B register 308 in such a case is unknown to an attacker, aswill be explained in the next paragraph.

Returning to FIG. 7, we note a couple of simple additions to theinternal control lines (the inverter 338 and the two AND functions 340,342). The basic function of this additional logic is to disable thesecure core's output 318 during the execution of a “write_secret” securecommand. In contrast, the output 318 is enabled in the case of a valid“sign_msg” secure command. This way, a device can create (and export) asignature from any input message, based on its embedded secret. Thatsignature can only be recreated (authenticated) by some other entity whois in possession of that same embedded secret. It should be noted thatthere are a number of different potential means to embed this desiredfunctionality into the system all of which are contemplated herein; theexample shown in FIG. 7 is simply an easy-to-understand method by whichthis mechanism may be enabled.

At this point, we now have all of the pieces necessary to securelyregister (synchronize) a given secure core's embedded secret value withsome entity and to subsequently update (rotate) this secret in a simpleand secure manner. We will refer to this entity as a registration orprovisioning service, but it may be just simply be some other device.

In embodiments, the first part of the protocol (device registration) isa three-step process comprising acquiring the proper “permission” tocreate a new embedded secret for a given device from one entity (thedevice's current provisioning service), creating the new secret on thedevice itself (and thereby sharing it with a second entity) and thenfinally writing this newly-created secret to the secure core device.This registration process may be accomplished in three basic steps—andall without knowing the existing value of the device's embedded secretby the second entity. The latter part of the protocol involves updating(rotating) the device's embedded secret. This procedure can beaccomplished securely in a single step and may be repeated as many timesas necessary in order to keep the device's embedded secret (and thus,the device's secure operation) safe from compromise.

Following is a description of embodiments relating to secure deviceregistration portion of the protocol. The first step in this processinvolves the synchronization of a secure device's embedded secret valuewith some other entity. We will refer to a simple mechanism by which asecure device can be provisioned is the case where the device isinitially provisioned in a secure location (e.g., the device is safefrom eavesdropping during the initial provisioning process). FIG. 8 is asequence diagram illustrating an embodiment of a method for registeringa device (with a new provisioning service). FIG. 8 is described in thecontext to a first provisioning service (Provisioning Service A), asecond provisioning service (Provisioning Service B), and a secure core(Secure Core 1). In the example illustrated in FIG. 8, the initialpower-up state (Step 0) for the Secure Core 1 device is that containsDevice Secret 0 (e.g., its static embedded). As discussed earlier, thisDevice Secret 0 value need not actually be known by Provisioning ServiceA, but the secure core can nonetheless be managed by Service A becauseit is in possession of the proper external reference code values for the“sign_msg” and “write_secret” commands.

Step 1 in the registration process involves Provisioning Service Brequesting the secure core 1 device's “ServiceID” (i.e., which serviceprovider is the “owner” of the secure core 1 device). Secure Core 1responds in Step 2 with the identity of Provisioning Service A and itsown CoreID. In Step 3, Provisioning Service B then sends a request toService A for transfer of ownership of secure core 1. The subsequentresponse in Step 4 from Service A to Service B (which should betransmitted in encrypted form, since it contains sensitive information)includes the proper external reference code inputs for secure core 1 forthe “Sign_Msg” and “write_secret” commands. In Step 5, Service B thenuses the first of these two reference code inputs, to request securecore 1 to sign a message consisting of a locally-generated nonce value(Entropy_1). The resulting signature received back from the Secure Core1 in Step 6 device contains the resulting signature of the Entropy_1value, which is the same value that will be created by the device inresponse to a “write_secret” command containing the “Entropy_1” argumentin Step 7. This signature is also the new embedded secret (Device Secret1) for the secure core 1 device.

Note that this embodiment of a registration process may only be secureif the three transactions contained within the dashed line (Steps 4-6)(referred to as the “Pre-provisioning” process) are conducted within acontrolled environment (e.g., one that is free from eavesdroppers). Inthe pre-provisioning process cannot be conducted in a secureenvironment, then the value of the derived embedded secret should beencrypted prior to leaving the confines of the device. The use of apublic-private key pair in this case allows the managing service (i.e.,the service that currently “owns” the device) to specify apreviously-determined service to which the control of this device is tobe transferred. Note that this public-key encrypt method need onlyhappen once (in the case where the derived embedded secret must begenerated in a non-secure environment). In that case, then the use ofthe hash of the pre-selected service's public key as one of the inputsto the creating of the Internal Reference will cryptographically bindthe (public-key encrypted) derived embedded secret to that pre-selectedservice. This acts as protection against attackers who try to “hijack”the secure operation of a device by replacing the public key of thepre-selected service with that of a different service.

The description above thus describes embodiments of a basic foundationof a mechanism for synchronizing a secret between a simple secure deviceand a service provider. This synchronization (registration) processeffectively transfers transferring control of the device from oneservice to another in a secure fashion. While there are severalapproaches by which this ownership transfer can be accomplished (all ofwhich are contemplated herein), the example described above is a simplecase.

Now that Service B has acquired the prospective value of Device Secret 1(Step 6 of FIG. 9), then Steps 1-6 need never be repeated. In otherwords, once Service B has acquired both the requisite reference codesfor Secure Core 1, then it can perform the transition from the DeviceSecret 0 state to the Device Secret 1 state and from that state directlyto any subsequent device secret state without requiring the securedevice to report the resulting value. Thus, this device secret rotationcan be effected in the field by going directly from the power-on state(Step 0) to the “write_secret” command (Step 7).

FIG. 9 is a sequence diagram illustrating a “post-registration”provisioning process. In this manner, the entire initial keyprovisioning and key rotation protocol (Steps 0-6 in FIG. 9) in can beperformed in the open without fear of exposing any of the device'ssecrets to external observers. Each time the device's embedded secret isupdated, the Provisioning Service B can calculate the resulting embeddedsecret simply by sending the device a new external entropy value.

This can happen without requiring the device to calculate the new valueand then report it back to the service (as per Step 6 in FIG. 8). Thiscan happen indefinitely, as long as the service keeps a local copy ofthe device's current embedded secret (and the device reports back themost recent external entropy value that was used to create the currentembedded secret) as a part of its response to the “ServiceID” request,This way, the service need not archive the extra information (the mostrecent external entropy value) for all of the devices that it manages.

Earlier, we mentioned that the keyed hash-based KDF structure describedabove has an interesting property in that it behaves in a manner that issimilar to standard cryptographic Password-based Key DerivationFunctions (PBKDF's). In such systems, the user typically supplies a(low-entropy) password and the system then combines this password with arandom salt (nonce) and an iteration count (which defines how many timesthe KDF cycles the combined input through a one-way hash function) inorder to create an encryption key. NIST publication SP800-56A/B/C defineseveral options for such KDF's and these kinds of KDFs are alsostandardized in ISO-18033-2 specifications (hereby incorporated byreference in their entirety).

Some systems may have bandwidth limitations that prevent the servicefrom providing its managed devices large amounts of entropy in theexternal message data input. We can nonetheless make use of the basicconcepts contained within these standards to produce the maximum amountof effective security that can be accomplished within the limitations ofsuch a low-bandwidth system.

Thus, the mechanism outlined in the embodiment of FIG. 7 may be usedwith a truncated external message input data (as few as 4 bits may beenough for practical purposes, if the keys are rotated frequentlyenough). As mentioned above, the effective entropy for the MAC output ofthe keyed hash depends much more heavily on the entropy of the embeddedkey than that of the external input data. In fact, in the case ofmessage authentication, the entropy of the raw message data itself canact to produce a relatively high effective entropy in the derived MAC(the signature of the message data itself). This is primarily due to thefact that the structure shown in FIG. 7 uses a dual keyed hash structurewhere the key input for the authentication itself (the signaturegeneration portion—i.e., keyed hash B 304) is iterated at leasttwice—once for the KDF and a second time for each signature generation.Thus, even a highly-truncated input data field to the keyed hash maystill nonetheless provide sufficient effective entropy for the derivedkeys (from the first pass through keyed hash B 304) such that the keyrotation required in practice is much lower than other schemes where thefull key value must be effectively transmitted directly (even if it istransmitted in encrypted form).

While there is a certain cost of cycling through the keyed hash functiontwice at every node when the keys are in the process of being rotated,under normal use cases (i.e., during simple authenticated messagetransmission, the keyed hash B function need only be iterated once (permessage authentication).

In some cases, it may be desirable to provision the same embedded secretvalue to a number of devices. This can be referred to this as a “groupkey” scenario and it is useful to allow multiple devices to authenticateeach other's messages quickly and efficiently. For example, a vendor maywant to push software updates to a group of devices that share a sameauthorization code for a particular update that will be accepted by allof them, rather than creating a unique authorization code for each ofthe devices. In this example, certain portions of an embedded key (e.g.,serial numbers, etc.) can be masked out, or group numbers can be writtenin place of unique serial numbers, for example. Referring back to theembedded key depicted in FIG. 4, it can be seen that, even in the casewhere all devices possess the same embedded secret 404, they still couldnot impersonate each other, due to the fact that they must still havedistinct embedded keys (assuming, for example, that the devices haddistinct serial numbers).

Thus, in the case where any device of a particular group has the sameembedded key value (e.g., not just the same embedded secret), then wemay need to provide a mechanism for each device to identify itself asbeing part of a (known) group as well as ensuring that the device willhave the same embedded key value. One design that can support such ascenario is shown in the embodiment of FIG. 10. FIG. 10 is a blockdiagram of a secure core that supports group key operation. Theembodiment shown in FIG. 10 is similar to the embodiment shown in FIG.7, with the addition of the embedded secret G 350, and three AND gates340, 342, and 354. Note that the AND gate 342 enables the writing of anew group number into a group key register 356 in a secure manner.

Note that, in this the example shown in FIG. 10, some of the individualfields of the embedded key are broken out for clarity. The reason forthis is the differentiation in the visibility (and thus, how the data inthe field should be loaded) between the public portions of the embeddedkey (the CoreID field) and the private (embedded secret) portion of theembedded key.

The manner by which the “embedded secret G” 350 (e.g., the embeddedsecret portion of the group key) data is loaded includes the derivationof a MAC output from keyed hash B 304 (just as with the process forloading the embedded secret B register 308. However, in the case of agroup secret, the output of the keyed hash B 308 (the internal MACoutput value) is XOR-ed (via XOR function 352) with a correspondinginput field from the external message input data 312. This way, anentity that can correctly calculate the resulting internal MAC outputvalue can also create a separate value for “transforming” between theinternal MAC output value and the desired group secret. However, anattacker will have knowledge of neither the internal MAC output nor theshared group secret that is derived in this manner. Thus, if the valuefor the “group secret” is selected well (e.g., it has maximum entropy),then the knowledge of even a large collection of external message inputdata 312 will still not provide any information to an attacker about thevalue of the embedded secret for the group.

Although the invention has been described with respect to specificembodiments thereof, these embodiments are merely illustrative, and notrestrictive of the invention. The description herein of illustratedembodiments of the invention, including the description in the Summary,is not intended to be exhaustive or to limit the invention to theprecise forms disclosed herein (and in particular, the inclusion of anyparticular embodiment, feature or function within the Summary is notintended to limit the scope of the invention to such embodiment, featureor function). Rather, the description is intended to describeillustrative embodiments, features and functions in order to provide aperson of ordinary skill in the art context to understand the inventionwithout limiting the invention to any particularly described embodiment,feature or function, including any such embodiment feature or functiondescribed in the Summary. While specific embodiments of, and examplesfor, the invention are described herein for illustrative purposes only,various equivalent modifications are possible within the spirit andscope of the invention, as those skilled in the relevant art willrecognize and appreciate. As indicated, these modifications may be madeto the invention in light of the foregoing description of illustratedembodiments of the invention and are to be included within the spiritand scope of the invention. Thus, while the invention has been describedherein with reference to particular embodiments thereof, a latitude ofmodification, various changes and substitutions are intended in theforegoing disclosures, and it will be appreciated that in some instancessome features of embodiments of the invention will be employed without acorresponding use of other features without departing from the scope andspirit of the invention as set forth. Therefore, many modifications maybe made to adapt a particular situation or material to the essentialscope and spirit of the invention.

Reference throughout this specification to “one embodiment”, “anembodiment”, or “a specific embodiment” or similar terminology meansthat a particular feature, structure, or characteristic described inconnection with the embodiment is included in at least one embodimentand may not necessarily be present in all embodiments. Thus, respectiveappearances of the phrases “in one embodiment”, “in an embodiment”, or“in a specific embodiment” or similar terminology in various placesthroughout this specification are not necessarily referring to the sameembodiment. Furthermore, the particular features, structures, orcharacteristics of any particular embodiment may be combined in anysuitable manner with one or more other embodiments. It is to beunderstood that other variations and modifications of the embodimentsdescribed and illustrated herein are possible in light of the teachingsherein and are to be considered as part of the spirit and scope of theinvention.

In the description herein, numerous specific details are provided, suchas examples of components and/or methods, to provide a thoroughunderstanding of embodiments of the invention. One skilled in therelevant art will recognize, however, that an embodiment may be able tobe practiced without one or more of the specific details, or with otherapparatus, systems, assemblies, methods, components, materials, parts,and/or the like. In other instances, well-known structures, components,systems, materials, or operations are not specifically shown ordescribed in detail to avoid obscuring aspects of embodiments of theinvention. While the invention may be illustrated by using a particularembodiment, this is not and does not limit the invention to anyparticular embodiment and a person of ordinary skill in the art willrecognize that additional embodiments are readily understandable and area part of this invention.

Embodiments discussed herein can be implemented in a computercommunicatively coupled to a network (for example, the Internet),another computer, or in a standalone computer. As is known to thoseskilled in the art, a suitable computer can include a central processingunit (“CPU”), at least one read-only memory (“ROM”), at least one randomaccess memory (“RAM”), at least one hard drive (“HD”), and one or moreinput/output (“I/O”) device(s). The I/O devices can include a keyboard,monitor, printer, electronic pointing device (for example, mouse,trackball, stylus, touch pad, etc.), or the like.

ROM, RAM, and HD are computer memories for storing computer-executableinstructions executable by the CPU or capable of being compiled orinterpreted to be executable by the CPU. Suitable computer-executableinstructions may reside on a computer readable medium (e.g., ROM, RAM,and/or HD), hardware circuitry or the like, or any combination thereof.Within this disclosure, the term “computer readable medium” or is notlimited to ROM, RAM, and HD and can include any type of data storagemedium that can be read by a processor. For example, a computer-readablemedium may refer to a data cartridge, a data backup magnetic tape, afloppy diskette, a flash memory drive, an optical data storage drive, aCD-ROM, ROM, RAM, HD, or the like. The processes described herein may beimplemented in suitable computer-executable instructions that may resideon a computer readable medium (for example, a disk, CD-ROM, a memory,etc.). Alternatively, the computer-executable instructions may be storedas software code components on a direct access storage device array,magnetic tape, floppy diskette, optical storage device, or otherappropriate computer-readable medium or storage device.

Any suitable programming language can be used to implement the routines,methods or programs of embodiments of the invention described herein,including C, C++, Java, JavaScript, HTML, or any other programming orscripting code, etc. Other software/hardware/network architectures maybe used. For example, the functions of the disclosed embodiments may beimplemented on one computer or shared/distributed among two or morecomputers in or across a network. Communications between computersimplementing embodiments can be accomplished using any electronic,optical, radio frequency signals, or other suitable methods and tools ofcommunication in compliance with known network protocols.

Different programming techniques can be employed such as procedural orobject oriented. Any particular routine can execute on a single computerprocessing device or multiple computer processing devices, a singlecomputer processor or multiple computer processors. Data may be storedin a single storage medium or distributed through multiple storagemediums, and may reside in a single database or multiple databases (orother data storage techniques). Although the steps, operations, orcomputations may be presented in a specific order, this order may bechanged in different embodiments. In some embodiments, to the extentmultiple steps are shown as sequential in this specification, somecombination of such steps in alternative embodiments may be performed atthe same time. The sequence of operations described herein can beinterrupted, suspended, or otherwise controlled by another process, suchas an operating system, kernel, etc. The routines can operate in anoperating system environment or as stand-alone routines. Functions,routines, methods, steps and operations described herein can beperformed in hardware, software, firmware or any combination thereof.

Embodiments described herein can be implemented in the form of controllogic in software or hardware or a combination of both. The controllogic may be stored in an information storage medium, such as acomputer-readable medium, as a plurality of instructions adapted todirect an information processing device to perform a set of stepsdisclosed in the various embodiments. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement insoftware programming or code an of the steps, operations, methods,routines or portions thereof described herein, where such softwareprogramming or code can be stored in a computer-readable medium and canbe operated on by a processor to permit a computer to perform any of thesteps, operations, methods, routines or portions thereof describedherein. The invention may be implemented by using software programmingor code in one or more general purpose digital computers, by usingapplication specific integrated circuits, programmable logic devices,field programmable gate arrays, optical, chemical, biological, quantumor nanoengineered systems, components and mechanisms may be used. Ingeneral, the functions of the invention can be achieved by any means asis known in the art. For example, distributed or networked systems,components and circuits can be used. In another example, communicationor transfer (or otherwise moving from one place to another) of data maybe wired, wireless, or by any other means.

A “computer-readable medium” may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, system ordevice. The computer readable medium can be, by way of example only butnot by limitation, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, system, device,propagation medium, or computer memory. Such computer-readable mediumshall generally be machine readable and include software programming orcode that can be human readable (e.g., source code) or machine readable(e.g., object code). Examples of non-transitory computer-readable mediacan include random access memories, read-only memories, hard drives,data cartridges, magnetic tapes, floppy diskettes, flash memory drives,optical data storage devices, compact-disc read-only memories, and otherappropriate computer memories and data storage devices. In anillustrative embodiment, some or all of the software components mayreside on a single server computer or on any combination of separateserver computers. As one skilled in the art can appreciate, a computerprogram product implementing an embodiment disclosed herein may compriseone or more non-transitory computer readable media storing computerinstructions translatable by one or more processors in a computingenvironment.

A “processor” includes any, hardware system, mechanism or component thatprocesses data, signals or other information. A processor can include asystem with a general-purpose central processing unit, multipleprocessing units, dedicated circuitry for achieving functionality, orother systems. Processing need not be limited to a geographic location,or have temporal limitations. For example, a processor can perform itsfunctions in “real-time,” “offline,” in a “batch mode,” etc. Portions ofprocessing can be performed at different times and at differentlocations, by different (or the same) processing systems.

It will also be appreciated that one or more of the elements depicted inthe drawings/figures can also be implemented in a more separated orintegrated manner, or even removed or rendered as inoperable in certaincases, as is useful in accordance with a particular application.Additionally, any signal arrows in the drawings/figures should beconsidered only as exemplary, and not limiting, unless otherwisespecifically noted.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having,” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,product, article, or apparatus that comprises a list of elements is notnecessarily limited only those elements but may include other elementsnot expressly listed or inherent to such process, product, article, orapparatus.

Furthermore, the term “or” as used herein is generally intended to mean“and/or” unless otherwise indicated. For example, a condition A or B issatisfied by any one of the following: A is true (or present) and B isfalse (or not present), A is false (or not present) and B is true (orpresent), and both A and B are true (or present). As used herein, a termpreceded by “a” or “an” (and “the” when antecedent basis is “a” or “an”)includes both singular and plural of such term (i.e., that the reference“a” or “an” clearly indicates only the singular or only the plural).Also, as used in the description herein and throughout the claims thatfollow, the meaning of “in” includes “in” and “on” unless the contextclearly dictates otherwise.

What is claimed is:
 1. A method for provisioning a device with anembedded secret comprising: providing a first embedded key register inthe device; providing a second embedded key register in the device;providing a pair of keyed hash functions in the device; permanentlywriting a first value into the first embedded key register of the deviceto create an embedded secret; and creating an external reference code byhashing an external reference code using one of a pair of keyed hashfunctions, wherein the keyed hash function is keyed using the embeddedsecret and creating the external reference code comprises transferringthe contents of the first embedded key register to the second embeddedkey register of the device when the device powers-up and providing thecontents of the second embedded key register as a key to the one of thekeyed hash functions.
 2. The method of claim 1, further comprising,after device power-up, updating the contents of the second embedded keyregister with a second value derived from the first value permanentlystored in the first embedded key register.
 3. The method of claim 2,wherein the second value is derived from an external message input usingthe known value as a key to a hash function.
 4. The method of claim 1,further comprising providing an output by hashing a message input usingthe contents of the second embedded key register as the key to the oneof the keyed hash functions.
 5. The method of claim 4, wherein themessage input is received from an external source.
 6. The method ofclaim 5, further comprising: receiving a reference code input value; andcomparing the received reference code input value to a calculatedreference; and conditioning the availability of the internal outputbased on the comparison of the received reference code input value tothe calculated internal reference.
 7. The method of claim 6, wherein theinternal output is made available only when the received externalreference code input value matches the calculated internal reference. 8.A system for provisioning a device with an embedded secret comprising: aprocessor; first and second embedded key registers; and the device isadapted to: permanently write a first value into the first embedded keyregister of the device to create an embedded secret; and create anexternal reference code by hashing an external reference code using oneof a pair of keyed hash functions, wherein the keyed hash function iskeyed using the embedded secret and creating the external reference codecomprises transferring the contents of the first embedded key registerto the second embedded key register of the device when the devicepowers-up and providing the contents of the second embedded key registeras a key to the one of the keyed hash functions.
 9. The system of claim8, further comprising, after device power-up, updating the contents ofthe second embedded key register with a second value derived from thefirst value permanently stored in the first embedded key register. 10.The system of claim 9, wherein the second value is derived from anexternal message input using the known value as a key to a hashfunction.
 11. The system of claim 8, further comprising providing anoutput by hashing a message input using the contents of the secondembedded key register as the key to the one of the keyed hash functions.12. The system of claim 11, wherein the message input is received froman external source.
 13. The system of claim 12, further comprising:receiving a reference code input value; and comparing the receivedreference code input value to a calculated reference; and conditioningthe availability of the internal output based on the comparison of thereceived reference code input value to the calculated internalreference.
 14. The system of claim 13, wherein the internal output ismade available only when the received external reference code inputvalue matches the calculated internal reference.
 15. A non-transitorycomputer readable medium comprising instructions for provisioning adevice with an embedded secret by: permanently write a first value intoa first embedded key register of the device to create an embeddedsecret; and create an external reference code by hashing an externalreference code using one of a pair of keyed hash functions, wherein thekeyed hash function is keyed using the embedded secret and creating theexternal reference code comprises transferring the contents of the firstembedded key register to a second embedded key register of the devicewhen the device powers-up and providing the contents of the secondembedded key register as a key to the one of the keyed hash functions.16. The non-transitory computer readable medium of claim 15, furthercomprising, after device power-up, updating the contents of the secondembedded key register with a second value derived from the first valuepermanently stored in the first embedded key register.
 17. Thenon-transitory computer readable medium of claim 16, wherein the secondvalue is derived from an external message input using the known value asa key to a hash function.
 18. The non-transitory computer readablemedium of claim 15, further comprising providing an output by hashing amessage input using the contents of the second embedded key register asthe key to the one of the keyed hash functions.
 19. The non-transitorycomputer readable medium of claim 18, wherein the message input isreceived from an external source.
 20. The non-transitory computerreadable medium of claim 19, further comprising: receiving a referencecode input value; and comparing the received reference code input valueto a calculated reference; and conditioning the availability of theinternal output based on the comparison of the received reference codeinput value to the calculated internal reference.
 21. The non-transitorycomputer readable medium of claim 20, wherein the internal output ismade available only when the received external reference code inputvalue matches the calculated internal reference.